Many of today's enterprise-level software applications or “enterprise applications” are developed to run on computer servers known as “application servers”, an example of which is the WebLogic Server product (WebLogic) from BEA Systems, Inc. WebLogic is also an example of a Java 2 Enterprise Edition (J2EE) application server, i.e. it conforms to Java standards. Other application servers exist that also conform to these standards. To assist in developing applications, each of the various application server products typically includes an integrated software development counterpart (IDE), that assists the software developer in developing applications. For example, WebLogic includes an IDE known as WebLogic Workshop. WebLogic Workshop provides an intuitive programming model that allows the developer to focus on building the business logic of the application rather than on complex implementation details. Whether the developer is an application developer with a business problem to solve, or an expert J2EE developer building business infrastructure, WebLogic Workshop makes it easier to design, test, and deploy enterprise-class applications.
WebLogic Workshop comprises two main parts: the Workshop Integrated Development Environment (IDE) itself, and a Workshop runtime environment. The IDE simplifies the complexity in building applications for the entire WebLogic platform, since applications that are built in the IDE can be constructed from high-level components rather than low-level API calls. The applications can then be executed in the Workshop runtime environment. These applications typically expose systems and data using a combination of web applications and web services. For example, a company might want to expose shipment scheduling, tracking and billing data to it's business partners via web services, so that it's partners' applications can then access the data directly. The company might also want to expose tracking information via one or more web applications, so that shipment originators and recipients can check the status of their shipments using a web browser. WebLogic Workshop makes it easy to construct a common functionality for both applications, and then expose that functionality with the appropriate interfaces.
An application usually contains one or more “projects”. Projects are used to expose enterprise application logic via a user interface. Components within a project may reference each other, but generally they may not reference components in other applications. In this manner an enterprise application is different from a web application. The term “web application” generally refers to a collection of resources, typically HTML or JSP pages, that allow users to access functionality via the Internet or web. An enterprise application may contain one or more web applications. In WebLogic Workshop, there are a large variety of project types. Web Projects are constructed from Java Server Pages (JSPs), which can interact with server resources to produce dynamic content. Control Projects and Java controls are entities that contain business logic, or provide convenient access to enterprise resources. A control project may be used to construct and package controls that are intended for use by components in other projects. A Control Deliverable Project can be used to build Java controls that are then distributed to multiple users. A control deliverable project creates directories that store help and sample files relating to the control. Workshop then packages the controls of that project into a Java Archive (JAR) file along with the help and sample files. EJB Projects and Enterprise Java Beans (EJBs) are Java software components of enterprise applications, as defined by the J2EE Specification. An EJB Project provides support for creating and deploying new EJBs. A Java project allows development of general-purpose Java code that is not directly part of special entities such as web services, controls or EJBs. The product of a Java project is a JAR file that holds Java classes that need to be accessed from other parts of the application. A Schema project provides convenient, automatic access to BEA Systems' XMLBeans functionality. Portal Projects are used to provide a single point of access to enterprise applications and information that can be based on user, group and role attributes. A Datasync project is used to develop and manage general purpose portal services that are used in the development of personalized applications and portals, including user profiles, user segments, events, request properties, session properties, content selectors, placeholders, and campaigns. A Business Process Project allows the execution of business logic and the exchange of business documents among back-end systems, users and trading partners (systems and users) in a loosely coupled fashion.
Before an application can be executed, it must be “built”. How often a particular project must be built depends on the particular type of project. For example, if the developer is developing a web service, page flow, or JSP file in a Web or Web Service project, then they will not need to build the project that contains those files until they are ready to deploy the project. Web and Web Service projects can also be built incrementally. Java projects, control projects, EJB projects, and Schema projects are similar in that the result of building any of these projects is a JAR file that is written to the application's APP-INF/lib or class folder, which can then be used by other projects within the application. These projects are built when the JAR files need to be updated, so that the latest changes are available to any projects that are using them. Typically, the entire application needs to be built only when it is being deployed to a server. During the application build, the developer will perform a clean operation and then build the full application to generate an EAR file. Applications will probable be rebuilt again prior to deployment of the application to a production environment, or files are changed across multiple projects, especially if there may be dependencies between them. Depending on the size of the application, the application build process can take a long time, and may need to be repeated several times.
The WebLogic Workshop environment allows a developer to customize the way in which projects are built, including through the use of a tool called “Ant” (“Another Neat Tool”), developed by the Apache Software Foundation. Ant is a Java-based build tool, similar to a software “Make” utility, designed for use with both application-level and project-level Ant build files. If a developer wants to customize the way WebLogic Workshop builds an individual project, then they can use the Workshop IDE to export the ANT build file that Workshop then uses to build that project. When they then build the project, WebLogic Workshop will use the custom build file to create the project JAR. Similarly, if the developer wants to customize the way WebLogic Workshop builds an entire application, they can use the WebLogic Workshop IDE to export the ANT XML build file for the application. The exported Ant file contains a set of standard tasks and targets for managing the build for the application. Whereas make-like tools are inherently shell-based, evaluating a set of dependencies and then executing commands not unlike what the developer would issue on a shell; Ant can be extended using Java classes, and instead of writing shell commands, the configuration files can be XML-based, calling a target tree wherever various tasks get executed.
On of the problem with Ant-based scripting, or indeed any scripting language that is used for building applications, is that it typically must be invoked within the IDE. Most build-script tools cannot run within a command-line interface. Furthermore, a script is difficult to generate by hand, requiring the talents of a skilled programmer. If the script must be subsequently customized or tweaked, then another skilled programmer will have to take up that task. The net result is that, while build scripts such as Ant greatly assist in the application build and deployment process, they lack a flexibility and ease of use. Furthermore, there is no means to automatically generate the script to suit a particular project or application. This is the area that the present invention is directed to.